In the field of semiconductor design technology, a design rule check (DRC) is a well-known process for inspecting whether mask pattern data of a semiconductor integrated circuit is correctly designed in compliance with fabricators' topological layout rules (TLR). The TLR are unique to each fabrication facility, or semiconductor wafer plant, based on available process technologies, equipment limitations, etc. An example of prior art DRC system is illustrated in U.S. Pat. No. 6,063,132 incorporated by reference herein.
Integrated circuit designers transform circuit schematics to mask data by drawing polygons that represent the physical masks to be fabricated on silicon. For example, a transistor symbol on a circuit schematic could be represented by simply drawing a POLY layer polygon (gate region) crossing a DIFFUSION layer polygon (source and drain regions) and both polygons are laid within a WELL layer polygon. These mask pattern data are usually in well-known GDS format (binary) and are used by a design rule checker to check against design rules embodied in coded form in a design rule check command file.
FIG. 1 illustrates the basic flow of design rule checking on mask pattern data of an integrated circuit in accordance with a prior art routine 100. A design rule check (DRC) command file 120 is coded in accordance with a topological layout rule document 101. DRC command file 120 and the mask pattern data 130 (representing the physical layout of the IC) are used as inputs by a design rule checker 140 (typically a software routine) for design error detection and to generate a results list. Any subsequent design errors detected must be corrected in the layout proposed by the IC designer as shown in block 150. For some types of ICs, this process of checking the design errors can be automated, but for many others, it cannot.
A recent development in the IC industry has been the incorporation of memory and logic within the same IC, as found for example in embedded memory systems, and in so-called system-on-chip (SOC) designs. These systems present a unique challenge to the design process, because memory and logic circuits have different sizing, performance and scaling issues when embodied in silicon. Thus, logic and memory layout regions they must be treated differently during the verification process.
A first conventional method of checking design rules for an SOC design is described now with reference to the system 200 shown in FIG. 2. In the case of a semiconductor foundry (i.e., those plants that specialize in rendering third party designs into silicon) a design rule check command file 220 is written by referring to a Foundry's Topological Layout Rule document (TLR) 201. Therefore, this design rule command file typically only consists of so-called “Logic Rules” 210 applicable to a logic section of a chip under consideration. As before the Mask Pattern Data 230 for the chip is fed into a design rule checker 240 to check against these logic rules. The output of this process is a design rule check result file 250.
At this point, the results consist of real logic error(s) 251, false logic rule errors on memory blocks 252 and possibly real memory error(s) 253. The false logic rule errors 252 are caused by the fact that logic circuits implemented in silicon typically require greater spacings, sizings and margins than memory circuits. An extra step 260 thus has to be carried out to filter false error(s) from the other real errors reported in the result database. The typical method is by manual effort—i.e., human eye review and filtering. This can be extremely time consuming and cumbersome since the number of false design rule errors will increase relative to the number of memory blocks used and the size of each memory instance.
Thus, this approach flags many false DRC errors because each memory bit cells and associated leaf cells can cause many DRC violations that are not “true” because they do not actually violate a memory design rule that is applicable to the memory block. An operator has to manually check all the violations against a memory design rule check at step 270 to see if they are real errors. They then iteratively repeat this process to arrive at a set of real logic errors 271, and real memory errors 272. Nonetheless, this process can often cause real errors to be overlooked. Furthermore, this process slows down the design development cycle because each error must be discussed with the IC design supplier, and this interaction can be time consuming as it requires cooperation between the IC designer, the foundry field support engineers, and the foundry itself.
A second conventional method of checking design rules is described below with system 300 referenced in FIG. 3, where like numbers are intended to denote like structures and operations unless otherwise noted. In this approach, a Cell Delete or Masking technique 310 masks out the whole memory instance including memory bit cell arrays and other associated logic support circuitry such as wordline decoder, sense amplifier, etc. from design rule checks performed by checker 340 on GDS file 330. The design rule check (DRC) results 350 will thus consist only of real logic errors 351. However, this method assumes the memory blocks used are DRC clean and that the interfaces (or intermediate regions) between the memory and logic parts satisfy logic rules. Consequently, it will not detect any real errors in such features.
Accordingly, a substantial need exists in this field of art for an improved design verification tool that eliminates the aforementioned problems.